I am using this forum for the first time, and I'm not clear on the policies (to me this seems to be designed more like an Apple Store than a developer forum). The "Learn more about the forums" is of no help in this regard, and I have therefore no idea what the Post Visibility is for (i.e. maybe for beta software??). I mean, there isn't even a BigSur tag, yet?!? So I'll just post a few things here and see if I'm getting kicked out or silenced and then I know not to try this again. I mainly like to get some feedback in the form of "yes, I can confirm this issue" so that I have a better idea what is a bug and what is just me doing something wrong or doesn't affect anyone else. Issues with BS Beta 3 on a DTK system: I tried running Geekbench 4 and 5. Both run, but when they try to report the results, both open Safari, which then tell me that the URL is somehow invalid. So I never succeed in seeing the results. Does this work for others? 2. I have attached a USB 3.1 SSD via a USB-C-to-C cable to the Mac. When I read large amounts of data (e.g. a 10 GB file) from it, then often the file read comes to a stall, and it takes very long to finish. When I use a USB-C-to-A cable (A-connector goes into the Mac), so that it's USB 3.0, then there's no such stalling. Can anyone else reproduce this? 3. Whenever I try to trash (i.e. delete, as it doesn't have a Trash folder) an app bundle from my NAS that's connected via SMB, I get a system (kernel?) crash with a hard reboot. Anyone else?

I have both a Mac Mini 2018 and a VMware (preview build 16530630) system with BS Beta 2 (20A4300b) running. Both offer the beta 3 update, even both the universal installer with 12.9 GB (which I used successfully to update the DTK, where I didn't get the automatic update offered yet), and the Intel-only installer with about 5-6 GB. I tried to use both installers on both machines, and every time there seems to be a kind of crash in the middle of installation, and then the system reboots into beta 2. Both systems are installated in their own APFS container (no sharing with 10.15.x). This should be the most basic config. The Mac Mini has about 35 GB of free space, and the BM even over 60 GB. That should be plenty. Any ideas how to fix that? Anyone else having the same problem? Or an idea how to find the log & error msgs the updater may report? I could, of course, re-install from scratch, but I'd only use that as a last resort. Still hoping this can be solved.

I'm making (non-sandboxed) Mac applications for in-house use (which is a controlled, and hence trusted, environment). I waste a lot of time debugging and meeting notarization and the many other app deployment requirements (entitlements, permissions for scripting other apps, accessing "protected" folders etc.). This is costly for us, too, both in time and financially. All these security measures should not be necessary in our controlled environment - we inherently trust our own software, after all. Is there some way to disable these checks, or at least some of them? Perhaps with special certificates that broadly grant all these permissions to all our own apps on our own Macs?

I keep getting a particular type of crash report for my macOS app (FAF) that I cannot figure out. Here's the top of the stack trace which all reports have in common: Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libobjc.A.dylib … objc_msgSend + 29 1 com.apple.AppKit … -[NSPathControl _performDragOfCell:fromMouseDown:] + 130 2 com.apple.AppKit … -[NSPathControl mouseDown:] + 300 3 com.apple.AppKit … -[NSWindow(NSEventRouting) _handleMouseDownEvent:isDelayedEvent:] + 4961 What I figured out so far: Is triggered by a click or double click on a segment of the NSPathControl. For some users it has been happening more than once, but not often enough for me to figure out what's behind it. I have not been able reproduce it even once. Leads to a "Segmentation fault: 11" Happens in macOS versions from at least 10.8 until the most current (11.4). In both Intel and ARM code. The call stack does not show any of my own code involved. The app's other threads are all idle. Some reports do not list any non-Apple extensions or dylibs as far as I can tell. When I googled "crash NSPathControl setHighlighted", I could only find a single other mention of it, but that crash even happened in Finder, on OSX 10.8.1. The person reporting it had quite a few other system extensions loaded but eventually figured out that it got fixed when he changed his Wacom tablet's behavior from not issuing a triple click any more. I tried to create triple clicks, along with combined drags, even using SteerMouse to have a triple click event generated by a separate mouse button, but to no avail. Has anyone else seen this type of crash? Any idea what may be behind this? I have two complete crash reports (with only some privacy related lines removed at the top) uploaded here: https://gist.github.com/tempelmann/5c519244ffc7a485afa66d546a9b9712 https://gist.github.com/tempelmann/315f8122b8079637cb5a9bf299ac380a

My macOS app reads the crashlog files directly and submits them to my server for analysis if the user allows it. Which means I get to see the original .ips files generated on Monterey. Now, these files appear to contain two JSON-formated records, the first detailing the app's properties. Here's a reformatted example of that as reported for my own app: { "app_name":"Find Any File", "timestamp":"2022-01-02 10:12:36.00 -0500", "app_version":"", "slice_uuid":"a15335de-4432-3b53-bcdf-381424a7a330", "build_version":"", "platform":1, "share_with_app_devs":0, "is_first_party":1, "bug_type":"309", "os_version":"macOS 12.1 (21C52)", "incident_id":"132818BA-3DBA-4B15-86CE-307BE961E7DC", "name":"Find Any File" } The problem for me here is that sometimes, like in this example, both the app_version and the build_version values are empty. That makes it difficult for me to figure out which version of my app caused the crash. I have 11 .ips crash reports, and when I compare the ones with valid version information against those missing them, the only consistency I find is that the value for is_first_party is 0 whenever I get valid versions, and 1 whenever I get empty values. Can anyone explain why this happens and how I can make this work in all cases? Note: One other developer (P.N.L.) has confirmed my findings, seeing empty versions as well, occosionally, and also directly related to the is_first_party value. (I've also asked this on SO,, but it's not a good fit there)

TL;DR I cannot install some Apple software because a certificate appears to have expired. How do I identify the culprit? I have been using Xcode 10.1 on 10.13.6 for a many years on my MacBook Pro, and suddenly it won't launch any more because it wants to install the "additional required components", but then fails at doing so with a weird "untrusted" error message. From the log file: Xcode[12324]: Package Authoring Error: PackageInfo bundle reference found without top-level bundle definition. Bundle will be skipped: <bundle id="*"></bundle> Xcode[12324]: Package: PKLeopardPackage <id=com.apple.pkg.MobileDeviceDevelopment, version=10.3.9000000000.1.1488876279, url=file:///Applications/Xcode10.1.app/Contents/Resources/Packages/MobileDeviceDevelopment.pkg> Failed to verify with error: Error Domain=PKInstallErrorDomain Code=102 "The package “MobileDeviceDevelopment.pkg” is untrusted." UserInfo={NSLocalizedDescription=The package “MobileDeviceDevelopment.pkg” is untrusted., NSURL=MobileDeviceDevelopment.pkg -- file:///Applications/Xcode10.1.app/Contents/Resources/Packages/, PKInstallPackageIdentifier=com.apple.pkg.MobileDeviceDevelopment, NSUnderlyingError=0x7f8240512710 {Error Domain=NSOSStatusErrorDomain Code=-2147409654 "CSSMERR_TP_CERT_EXPIRED" UserInfo={SecTrustResult=5, PKTrustLevel=PKTrustLevelExpiredCertificate, NSLocalizedFailureReason=CSSMERR_TP_CERT_EXPIRED}}} Everything else works fine on the system. All I changed recently, before this started happening, was to re-install 10.13.6 fresh, and then restore from a recent Time Machine backup, all in order to fix an iCloud issue that seemed to be related to SSL trust issues when contacting the iCloud sync server, but was fixed with this re-install. I've even re-downloaded the Xcode10.1.xip from Apple, but that makes no differences, it's not Xcode that's broken. The log suggests that a cert has expired, but which one would that be? I have looked at the Certificates in Keychain Access, but none of the ones that appear to be related to Apple are expired as far as I can tell. Maybe one is missing, but which? Any ideas how to analyse or fix this? (I need Xcode 10.1 because the macOS apps I make need to remain backward compatible with 10.11 and up, and I'm often debugging on High Sierra for that purpose. Besides, the same Xcode 10.1 works fine on two other Macs running 10.13.6.)

I like to find a way to identify network volumes, and whether they're run by certain servers, e.g. specifically whether they're on a Synology NAS. Reason is that Synology, while apparently supporting the Spotlight-over-SMB API, comes with a lot of bugs, requiring me to work around them when searching on those volumes with the macOS Spotlight API. I could, of course, ask the user to "configure" each mounted volume in my software, but I'd rather do this automagically, if possible, as it's less prone to user mistakes. So, my question is: Is there a way to learn a bit more about the server of a mounted network volume? E.g., if I could learn its IP address, I could try to connect to it via http protocol and then maybe get a useful response that identifies it as being from Synology. Or, alternatively, can I tell which SMB volumes are served by a Mac, so that I can at least assume that those handle Spotlight calls correctly, while I assume anything else is buggy (so far, AFAIK, Synology is the only other SMB server that supports Spotlight search). I've tried to find some data in the IORegistry, but that doesn't seem to store anything about network vols. The statfs function doesn't seem to give me anything for that either, nor do the various fcntl calls as far as I could tell. I also checked with the DA apis, e.g.: DASessionRef daSession = DASessionCreate (NULL); CFURLRef furl = CFURLCreateWithFileSystemPath(NULL, CFSTR("/Volumes/TheNAS"), kCFURLPOSIXPathStyle, true); DADiskRef daDisk = DADiskCreateFromVolumePath (NULL, daSession, furl); if (daDisk) { CFDictionaryRef daInfo = DADiskCopyDescription (daDisk); NSLog(@"%@", daInfo); } However, this only prints basic information: DAVolumeKind = smbfs; DAVolumeMountable = 1; DAVolumeName = TheNAS; DAVolumeNetwork = 1; DAVolumePath = "file:///Volumes/TheNAS/"; Where, then, does Finder's "Get Info" get the smb path from, for example?

I have received a few crash reports for my app "Find Any File" with an assertion failure as follows: assertion failure: "displayTiming != ((void *)0)" -&gt; %lld Googling this turns up nothing, though. I wonder if someone has some insight into why this might happen, and how to prevent it. One reporting user suggests that it happens when my app shows a very long list of items in an NSTableView (&gt;10000 elements). I have 4 reports from 3 users, and the main thread is doing something related to the table view each time, though not the same (the few other threads are all idle): Crash 1, in macOS 14.0 (23A344: Thread 0:: Dispatch queue: com.apple.main-thread 0 libobjc.A.dylib 0x182c69400 objc_msgSend + 0 1 AppKit 0x186f15400 -[CALayer(NSViewVisibleRect) NS_viewVisibleRectDidChange] + 40 2 AppKit 0x186900e10 NSViewHierarchyInvalidateVisibleRect + 276 3 AppKit 0x186900db0 NSViewHierarchyInvalidateVisibleRect + 180 4 AppKit 0x186900db0 NSViewHierarchyInvalidateVisibleRect + 180 5 AppKit 0x186900db0 NSViewHierarchyInvalidateVisibleRect + 180 6 AppKit 0x186900db0 NSViewHierarchyInvalidateVisibleRect + 180 7 AppKit 0x186900db0 NSViewHierarchyInvalidateVisibleRect + 180 8 AppKit 0x1869990e0 -[NSView translateOriginToPoint:] + 164 9 AppKit 0x186984108 -[NSClipView _immediateScrollToPoint:] + 420 10 AppKit 0x186983eb8 -[NSClipView scrollToPoint:] + 184 11 AppKit 0x186998d80 -[NSScrollView scrollClipView:toPoint:] + 84 12 AppKit 0x1869448dc -[NSClipView _scrollTo:animateScroll:flashScrollerKnobs:] + 480 13 AppKit 0x186b65b24 __62-[NSScrollingBehaviorConcurrentVBL _stopGestureScrollTracking]_block_invoke + 192 14 AppKit 0x186e6a6e8 ___NSMainRunLoopPerformBlockInModes_block_invoke + 44 15 CoreFoundation 0x18310b8c0 __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 28 Crash 2, in macOS 14.1.1 (23B81): Thread 0:: Dispatch queue: com.apple.main-thread 0 CoreFoundation 0x18ba401f4 DYLD-STUB$$_Block_object_assign + 0 1 libsystem_blocks.dylib 0x18b506118 _call_copy_helpers_excp + 80 2 libsystem_blocks.dylib 0x18b505c68 _Block_copy + 376 3 libdispatch.dylib 0x18b641c7c _dispatch_Block_copy + 32 4 libdispatch.dylib 0x18b658df0 _dispatch_source_set_handler + 92 5 CoreFoundation 0x18b99e1e4 __CFRunLoopCopyMode + 540 6 CoreFoundation 0x18b8b7458 CFRunLoopAddObserver + 220 7 AppKit 0x18f0a687c _PerfAddRunLoopObserver + 192 8 AppKit 0x18f87cd60 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 368 9 AppKit 0x18f323318 -[_NSScrollingConcurrentEventMonitor startMonitoring] + 380 10 AppKit 0x18f321df8 -[NSScrollingBehaviorConcurrentVBL _scrollView:trackGestureScrollWithEvent:] + 884 11 AppKit 0x18f2e67f8 -[NSScrollingBehaviorConcurrentVBL scrollView:scrollWheelWithEvent:] + 512 12 AppKit 0x18f241770 forwardMethod + 252 13 AppKit 0x18f2e62a0 -[NSView scrollWheel:] + 408 14 AppKit 0x18f241770 forwardMethod + 252 15 AppKit 0x18f2e62a0 -[NSView scrollWheel:] + 408 16 AppKit 0x18f241770 forwardMethod + 252 17 AppKit 0x18f2e62a0 -[NSView scrollWheel:] + 408 18 AppKit 0x18f241770 forwardMethod + 252 19 AppKit 0x18f2e62a0 -[NSView scrollWheel:] + 408 20 AppKit 0x18fc45880 -[NSCollectionView scrollWheel:] + 180 21 AppKit 0x18f241770 forwardMethod + 252 22 AppKit 0x18f241770 forwardMethod + 252 23 AppKit 0x18f2e62a0 -[NSView scrollWheel:] + 408 24 AppKit 0x18f241770 forwardMethod + 252 25 AppKit 0x18f2e62a0 -[NSView scrollWheel:] + 408 26 AppKit 0x18f241770 forwardMethod + 252 27 AppKit 0x18f2e62a0 -[NSView scrollWheel:] + 408 28 AppKit 0x18f1d27b0 -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 652 As you can see, there's no code of mine involved at the time of crash. The other (and older) reports are similar, in macOS 13.6.1 and macOS 13.1. All four happened on ARM architecture (which may not be significant due to small number of samples). Memory use of app was not critical (in one case it was about 9 GB total, in others below 4 GB). The "Binary Images" section only lists Apple libs, apart from my app's. So, there seems to be no 3rd party ext involved. I've attached a full report as well. Full report of Crash 1

sample.ips.txt Xcode, MacSymbolicator and QuickLook all fail to consider the symbols from the lastExceptionBacktrace of a modern .ips crash report. I have attached a full report as an example (I had to change its extension to txt or I wouldn't be able to upload it - change it back to ips and then use Quicklook to see its contents, which will be missing the backtrace). Here's the excerpt that matters: "lastExceptionBacktrace": [ { "imageOffset": 992564, "symbol": "__exceptionPreprocess", "symbolLocation": 164, "imageIndex": 13 }, { "imageOffset": 106164, "symbol": "objc_exception_throw", "symbolLocation": 60, "imageIndex": 25 }, { "imageOffset": 274836, "symbol": "-[__NSDictionaryM setObject:forKeyedSubscript:]", "symbolLocation": 1176, "imageIndex": 13 }, This trace is missing from a symbolicated report - I only get to see the main threads. Here's the start of that report: ------------------------------------- Translated Report (Full Report Below) ------------------------------------- Process: Find Any File [2616] Path: /Applications/Find Any File.app/Contents/MacOS/Find Any File Identifier: org.tempel.findanyfile Version: 2.4.1 (355) Code Type: ARM-64 (Native) Parent Process: launchd [1] User ID: 0 Date/Time: 2024-01-09 11:31:33.8066 -0600 OS Version: macOS 14.3 (23D5043d) Report Version: 12 Anonymous UUID: E3DD5ECE-F28C-31BA-A2EA-DE39D4284163 Time Awake Since Boot: 990 seconds System Integrity Protection: enabled Crashed Thread: 11 Dispatch queue: Folder size calc (Macintosh HD) (QOS: UNSPECIFIED) Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: Namespace SIGNAL, Code 6 Abort trap: 6 Terminating Process: Find Any File [2616] Application Specific Information: abort() called Thread 0:: Dispatch queue: com.apple.main-thread 0 CoreAutoLayout 0x18cecbdd8 -[NSISEngine hasValue:forEngineVar:] + 284 1 AppKit 0x187f51894 NSViewActuallyUpdateFrameFromLayoutEngine + 128 2 AppKit 0x187f11790 -[NSView layout] + 636 Contrary to this, when I get a similar crash report from an older macOS version where it still uses the older .crash instead of .ips files, I get to see the backtrace and can symbolicate it as expected. This seems to be a major bug in the symbolicator for ips files, and it's been around for years. I'm surprised that this is still not taken care of. Am I the only one who's noticing this?

On macOS, if I mount two volumes whose name is the same, the second one gets renamed, by appending "-1" to its name. I need a method to determine the original volume name, i.e. without such a suffix. (Of course, I cannot blindly remove any "-" plus digits because the volume may actually be named like this.) I can find the original name when using the mount command in Terminal: //tt@192.168.61.121/NAS2 on /Volumes/NAS2 (smbfs, nodev, nosuid, mounted by tt) //tt@QNAS%28AFP%29._afpovertcp._tcp.local/NAS2 on /Volumes/NAS2-1 (afpfs, nodev, nosuid, mounted by tt) Here, I can tell that "/Volumes/NAS2-1" was originally named "NAS2" on the network. How do I determine the share's name without invoking such tools, but via CF or other macOS functions, with providing the path or URL of the mounted volume (such as "/Volumes/NAS2-1")?

When using the mount command on macOS, I can see mounted network servers like this: //tt@mynas.local/NAS on /Volumes/NAS (smbfs, nodev, nosuid, mounted by thomas) In this example "thomas" is my macOS user name, under which I mounted the "NAS" volume. But there's also the "tt" name before the "@" - and that's what I'm interested in getting - that's the user name known to the server, i.e. the name I logged in on the server when the connection prompt appeared. How do I get this name (tt) via macOS APIs? I can get it via "mount", but that requires parsing and is inefficient, and so I like to avoid that if possible. man mount mentions getfsent(), but in my testing it only lists internal volumes, not network volumes.

I have two apps that are exempt from the need to be sandboxed. One has been in the MAS since the first day in 2010, and the other was added only a bit later, when there still was no sandboxing in place. When Apple added requirements for sandboxing, they exempted existing apps like mine under certain conditions. For years, this was no problem, but lately, nearly every other time I submit an update or a TestFlight beta, I get the app rejected for not being sandboxed, even though I explain the situation in the app's Review Notes. It's always a tedious fight convincing the reviewer to let the app pass. And, of course, it delays my releases each time. It's frustrating and exhausting. Sadly, I cannot find any public documents that confirm my claim of this exemption. So, it's always possible that the reviewer may read my note but still not believe me. Are there others here who still have such non-sandboxed in the MAS? How do you deal with this? Or do you know of documents or websites that I can refer the reviewer to?

Update: Turns out it works for others, apparently, and I also found one of my Macs where it does work, too. So it must be something pertinent to my systems. Oddly, though, the same ones where it now fails used to work because I had TestFlight enabled there before. I have TestFlight set up on App Store Connect, and I have already about 50 testers subscribed. Today, I found that the Public Link does not work any more: Once TestFlight.app is installed, and one clicks the link to add my app to TestFlight, it always shows the error ""Unable to Open Link" in TestFlight.app: I've tried this on several Macs (Ventura and Sonoma), and with different Accounts, both where the app was already added or not. Is something generally broken, i.e. do others see the same issue with their TestFlight links, or is it just me? How do you suggest I get this resolved? Here's an example link I set up for this purpose - it only allows a handful of subscribers, so please do not actually subscribe but just see if you even get allowed to, or if you get the same error if you must try: https://testflight.apple.com/join/oV8NNojg And here's how it's set up:

Imagine you accidentally made a build of your app with version 2 and uploaded that to App Store Connect for TestFlight even though you're still working on version 1.x and continue to do so with your public releases. Here's an example: The build 55 is the accidental 2.0 version, but the current releases are 209 and 210 with a lower string version. So, that one build of version 2 was a mistake. Sadly, you cannot remove it, even it has expired, even if it has never seen the outside of TestFlight. And it's a bit annoying too, because it stays up there at the top of your builds, and always presents the outdated version when you visit that page on App Store Connect. But worse is the fact that because of this, any version 1.x you release since then will not get you any crash reports or feedback that the user may have submitted to you. This is clearly a bug, and I was able to verify this just recently. I suspect this happens because Apple wants to avoid storing and forwarding reports for outdated versions, maybe to save space on their servers. That makes somewhat sense, though I've also had people finding crashes in older versions that were not fixed in the latest version, so I'd still like to get those reports from older versions. However, if Apple really only wants to keep crash reports and feedback msgs from the latest release, then Apple's mistake is that they use the unreliable string version to check which is the latest version instead of using the build number, which is ENFORCED by Apple to always be incrementing for each upload. If you are in the same boat, please comment so that we can make it clear to Apple that this is not an isolated issue.

Has anyone else seen this happen with their macOS apps in TestFlight? The situation: When I launch my app that's been downloading via TestFlight.app, it often comes up with its main window deactivated. Also, when I have open more than one window and close one, the other window doesn't come to front either. In either case, activating the app or clicking into a window will activate it properly. It feels as if there's another window that's not visible but somehow keeps getting activated. I have this happen on two Macs running both Sonoma and Monterey. Also, if I take the very same build that I had uploaded to TestFlight and run it directly, it works correctly. So I suspect that TestFlight somehow messes with my app's windows. If you want to test this yourself: Get the app thru this link: https://findanyfile.app/TestFlight/ Then launch it. Often, the Find window will already come up without being active. Activate it, then open the Preferences window by typing cmd-comma. Then close the Prefs window with cmd-W. This should re-activate the Find window but will instead leave it deactivated, and none of the menu shortcuts (such as cmd-comma, cmd-N or cmd-Q) work. That's the bug. I wonder how I can debug this to find a work-around for this odd behavior. E.g, I'd like to see if there is indeed a semi-hidden window causing this. How would I do this? I could probably make a new TestFlight build that queries the app's windows array and logs it. But are there other ways to query an app's windows? I tried AppleScript, but since my app isn't scriptable, I only get an error -1728 for tell app "Find Any File" to get windows.